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Regulated Issuance of Digital Certificates 

Abstract 

This invention allows a Certifying Authority (CA) in a Public Key Infrastructure (PKI) to allow 
a sub-CA to issue a pre-determined number of certificates without excessive overhead by the 
former CA. The regulation is performed by means of a security token that includes a count of 
the number of certificates issued by the sub-CA. 
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Claims 



What is claimed is: 

1 . A m e thod for providing a cryptographic tick e t to a trust e d modul e allowing that modul e to 

i s su e a pre d e t e rmin e d numb e r of public key certificat e s. 
2r. — A computer syst e m bas e d on th e m e thod of 1 . 

3. A computer sy s t e m bas e d on the m e thod of claim 1 where the trust e d module is a hardwar e 
tok e n such as a USB tok e n or a smartcard. 

4. A m e thod bas e d on claim 1 wh e r e th e cryptographic tick e t is a public k e y or privat e key 
c e rtificat e . 

5. A comput e r syst e m bas e d on th e m e thod of 4 . 

— A comput e r syst e m bas e d on th e m e thod of claim 4 wh e r e th e trust e d modul e is a hardwar e 
tok e n such as a USB tok e n or a smartcard. 

1. A m e thod bas e d on claim 1 wh e r e th e pr e d e t e rmined number of c e rtificat e s that can b e 
issu e d is d e t e rmined by information within th e provid e d cryptographic ticket. A computer 
system and one or more trusted modules associated with the computer system where the 
computer system can generate cryptographic tickets intended to be transmitted to one or 
more of the trusted modules allowing intended trusted modules to issue a set quantity of 
public-key certificates on request from users of the trusted modules, the certificates issued by 
the trusted modules consisting of (D components that are constrained by the trusted module 
and (ii) other components of the certificates able to be specified by the requesting user. 

7t2.A computer system based on claim 1 where the trusted module is a tamper-proof hardware 
security module or a USB token or a smartcard. 

Sr3. A computer system based on th e m e thod of 7 claim 1 where the cryptographic ticket is a 
public-key or private-key certificate . 
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4. A computer system based on claim 3 where t he method of t rusted module is a tamper-proof 
hardware security module or a USB token or a smartcard. 

5. A computer system based on claim 7 -1 where the set quantity of certificates that can be issued 
is determined by information within the provided cryptographic ticket. 

6. A computer system based on claim 5 where the trusted module is a tamper-proof h ardware 
token such as a security module or a U SB token or a smartcard. 
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Description 



INTRODUCTION 

[0440 0001] This invention relates to a system and method for regulation of the issuance of 
digital certificates. 

BACKGROUND 

[02W0002] Industry is increasingly making use of digital certificates to implement electronic 
authentication of entities, which could be individuals, organisations, computers etc. Public Key 
Infrastructure [PKI], [1] is a system whereby central agencies are given the role of Certifying 
Authorities (CAs) and these CAs produce certificates for sub-entities. Such certificates certify 
the keys of each entity and enable entities to communicate with confidence as to the authenticity 
or confidentiality of such communication. 

{033©[0003] Often a national agency will perform the role of a central or root CA and certify 
sub-CAs which then certify end-users or even lower levels of CAs. Certificates are commonly 
based on the X509 standard [1] and this standard allows a certificate to state if the certified entity 
is authorised to certify other entities. 

{0250[0004] Issuance of certificates by a root CA involves significant cost to provide security 
mechanisms that give confidence that fraudulent certificates are not produced. This cost is 
recovered by sales of certificates. If a certificate is for a CA that will be issuing certificates then 
the price of this CA's certificate will be related to the number of sub-certificates that will be 
produced. 
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{0340[0005] For larger corporations, the numbers of certificates can be accounted for using 
standard business reporting processes. For smaller corporations, this mechanism is not 
economic. 

SUMMARY OF THE INVENTION 

[0340 0006] The present invention describes a method whereby the issuance of certificates by a 
CA can be regulated with a security mechanism that does not require additional business 
processes. 

| 0320 ["00071 The CA is provided with a security token (trusted module) 103 containing the 
certifying key of the CA and a certificate, Cx, that authorises that CA to issue certificates for 
other entities 106. typically within the organisation represented by the CA. The security token 
also includes the public key of the issuer to enable validation of certificates presented to the 
token. The security token is tamper-resistant to prevent copying of the private certifying key or 
tampering with the issuer public key or other stores within the token. 

f0^0 [0008] The security token also includes a counter of the number of times that the 
certifying key is used to certify information presented to the token. The security token also 
includes a threshold count. Once the certifying counter reaches the threshold count, the 
certifying key mechanism is disabled. 

r03401 If a n e w certificate, Cy, is r e c e iv e d for th e CA the security tok e n [00091 The CA can be 
su pplied with a cryptographic ticket 102 from the controlling authority 101 to enable further 
certificate issuance. This cryptographic ticket is presented to the security token. In the invention 
this is a digital certificate. The certificate. Cv« is presented by CA to the security token which 
will confirm that the certificate is valid using the stored certifying key. If the certificate, Cy, is 
valid and the certificate is newer than the existing certificate, Cx, then Cy will be used to replace 
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Cx and the count of issued certificates will be cleared. The loading of the new certificate, Cy, 
thereby enables issuance of further certificates by the token. 

f0350[0010] An alternative to checking that Cy is newer than Cx is that the token can maintain a 
list of the identity of previously-loaded Cx. The new Cy would be checked against that list to 
prevent reload of an already-used certificate. 
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BRIEF DESCRIPTION OF THE DRA WINGS 

[001 1] FIG 1 is a block diagram illustrating the core entities and major process flows of the 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
[Q54-Q 0012] The following embodiment is based on a security token 103 t hat is based on a smart 
eaf dsmartcard or USB token running the MULTOS[2] operating system and with a proprietary 
application, AP. This specific embodiment concerns the case where a CA, CAext, wishes to 
authorise a small organisation to issue certificates for individuals within that organisation. CAext 
will be authorising a C A within the small organisation, C A^t, to issue certificates to individuals 
associated with the organisation. 

f0530{0013] The MULTOS application provides a standard IS07816 command/response 
interface [3,4] which implements the following commands (amongst other commands): 

[0530 [00141 LOGIN - a user or security office can present a command containing a PIN and, if 
valid, the PIN will unlock the card. If a pre-determined number of invalid PINs are presented 
sequentially, the card will then ignore further commands ie will be locked. 

f0540 r0015] LOADKEY - this command is available when a security officer is logged-in and is 
intended for card production. This command is used by CAext to load the keys intended for 
CAint. These keys will then be used by CAj nt to certify (issue) other certificates. The 
LOADJCEY operation resets the loaded certificate 'not-before' date. The LOADKEY 
command is also used to load the public key of CAext so that subsequent certificates issued by 
CAext can be verified. 
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ffl^0 r00161 LOAD_CERTIFICATE - the user or security officer must be logged-in. This 
command is used during card production and over the life of the card. The certificate to be 
loaded 102 is issued by OA** 101 and the public key of CAext that is within the card is used to 
verify that the certificate is authentic. The certificate references a specified Organisation and 
Organisational Unit in the X.509 Certificate subject name, see [1], p57. The X.509 standard also 
specifies a 'not-before' date, which specifies the date when the certificate becomes valid. If this 
date is older than the 'not-before' date of the existing certificate then the certificate load will fail 
as the certificate may have been used previously by the card to issue the allocated number of 
certificates and this may be an attempt to reload this certificate. 

[Q&€Q00VT\ GENERATE CERTIFICATE - The card application is presented with the core 
certificate information of user name and email addres s 104 . If the counter of issued certificates 
exceeds the maximum count allowed, the command will fail. Otherwise the counter is 
incremented and the card will construct and sign a certificate using the supplied user data and the 
preset Organisation and Organisational Unit data and return the certificate as response dat a 105 . 
The smart-card does not check the 'not-before' or 'not-after' X.509 dates prior to issuing a 
certificate, as the smart-card has no internal clock. This check is not essential as it is possible, 
and is an expected requirement, for any recipient application to verify that the validity dates of 
certificates in a chain of certificates are valid. 

fQ54 Q[0018] Although the invention has been described with reference to specific embodiments 
of the invention, it will be appreciated by those skilled in the art that it may be embodied in many 
other forms. 

***** 
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